home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Cream of the Crop 26
/
Cream of the Crop 26.iso
/
bbs
/
mxgui203.zip
/
MAXDOOR.DOC
< prev
next >
Wrap
Text File
|
1997-08-14
|
36KB
|
670 lines
╔═══════════════════════════════════════════════════════════════════════════╗
║ FIRST THINGS FIRST - READ THE FILE WARNING.TXT BEFORE PROCEEDING! ║
╚═══════════════════════════════════════════════════════════════════════════╝
┌╦══╦┐ ┌╦══╦┐ ┌╦═══╦┐
│╠══╩╗┐│╠══╩╗┐└╩═══╦┐
└╩═══╩┘└╩═══╩┘└╩═══╩┘
┌╦ ╦┐┌═╤╦╤═┐┌═╤╦╤═┐┌╔ ┌═╤╦╤═┐┌═╤╦╤═┐┌╔═══╦┐┌╔═══╦┐┌════╦┐
│║ ║│ │║│ │║│ │║ │║│ │║│ │╬══ │╬══ ┌─╔═╝─┘
└╩═══╩┘ ╧╩╧ └═╧╩╧═┘└╩═══╩┘└═╧╩╧═┘ ╧╩╧ └╩═══╩┘└╩═══╩┘└╚════┘
┌╦═══╦┐┌╦═══╦┐┌╔═══╦┐┌═╤╦╤═┐┌╦ ╦┐┌╦═══╦┐┌╦═══╦┐┌╔═══╦┐
└╩═══╦┐│║ ║││╬══ │║│ │║ ╦ ║│├╬═══╬┤│╠══╦╩┘│╬══
└╩═══╩┘└╩═══╩┘└╩ ╧╩╧ └╩═╩═╩┘└╩ ╩┘└╩ ╚═┘└╩═══╩┘ <tm>
A Subsidary Of LA-Soft
───────────────────────────────────────────────────────────────────────────────
▀▀▀▀▀▀▀▀ ▀▀▀▀▀▀ ▀▀ ▀▀
▀▀ ▀▀ ▀▀ ▀▀ ▀▀
▀▀ ▀▀ ▀▀▀ ▀▀▀▀▀ The DoorKit!
▀▀ ▀▀ ▀▀ ▀▀ ▀▀
▀▀ ▀▀▀▀▀▀ ▀▀ ▀▀
The BBS Door Development Kit By The People - For The People!
───────────────────────────────────────────────────────────────────────────────
The ANSI/ASCII/RIP/MAX DoorKit v1.36
No Copyright Notices Expressed Or Implied
Compiled By Larry L. Athey From Numerous Sources
───────────────────────────────────────────────────────────────────────────────
▀▀▀ ▀▀▀ ▀▀▀▀▀ ▀▀ ▀▀
▀▀▀▀ ▀▀▀▀ ▀▀ ▀▀ ▀▀ ▀▀
▀▀ ▀▀▀ ▀▀ ▀▀▀▀▀▀▀ ▀▀▀ ╔══ ╦═╗ ╔═╗ ╦═╗ ╦ ╦ ╦ ╔═╗ ╔═╗
▀▀ ▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ║ ╦ ╠╦╝ ╠═╣ ╠═╝ ╠═╣ ║ ║ ╚═╗
▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ╚═╝ ╩╚═ ╩ ╩ ╩ ╩ ╩ ╩ ╚═╝ ╚═╝
───────────────────────────────────────────────────────────────────────────────
The Universal Multimedia Interface For BBS Software
Copyright 1995-Current * Larry L. Athey * BBS Utiliteez Software
───────────────────────────────────────────────────────────────────────────────
Information Regarding MAX Graphics:
───────────────────────────────────
Notice is hereby given that the MAXscript/MAXcontrol/MAXcolor language,
and MAXterm are products of BBS Utiliteez Software and are protected by
US copyrights listed with the US Library Of Congress (1996)....
No changes, additions, subtractions, or other modifications shall be made
to MAXscript/MAXcontrol/MAXcolor language or the MAX Graphics development
kit without express written permission from Larry L. Athey, BBS Utiliteez
Software, Alliance, Nebraska, USA....
The MAXscript/MAXcontrol/MAXcolor language may be used in any BBS or Door
software 100% royalty free. You are also allowed to implement full local
graphics viewing in any BBS or Door software 100% royalty free. However,
any program that uses the MAXscript/MAXcontrol/MAXcolor language *MUST*
bear the MAX Graphics/BBS Utiliteez Software copyright notice....
Example: MAX Graphics and the MAXscript/MAXcontrol/MAXcolor language is
(C) 1995-Current * Larry L. Athey * BBS Utiliteez Software
Disclaimer:
───────────
MAX Graphics, MAXscript/MAXcontrol/MAXcolor and MAXterm are by no means
copies of, or otherwise plagiarized remote graphics methods used by any
other BBS software. Even though MAXterm responds to a few commands used
by RIPscrip and other RIP capable BBSes, this is by no means any kind of
a copyright infringement of the RIP technology. If it was, then I'm sure
that Pat Clawson of TeleGrafix would have notified me by now....
Yes, there are some similarities between MAX Graphics and some other BBS
graphical user interfaces, yet this is still not any kind of a copyright
infringement either. Since I have ran about every graphical BBS out there
from DOS to Windows platforms, I'm bound to create things in the image of
my own memory. Even the authors of other graphical BBS packages have told
me where they got their ideas....Other graphical BBS packages....So don't
worry if someone tells you "Gee, your BBS looks a lot like Shotgun BBS or
RoboBOARD/FX", all similarities if any are 100% within copyright laws....
....End of disclaimer....
───────────────────────────────────────────────────────────────────────────────
The Contributors:
─────────────────
This is a list of people who contributed to the cause of beta testing the
MAX Graphics related programs and the TDK door development kit. Although
there were more people who applied to be beta testers, most of these beta
sites never posted anything in the support echo, so I don't consider them
to have made any contribution to the cause. But, these people stood by me
and my efforts without a single sour word, and never threw in the towel..
Many people apply to be a beta tester for new programs and never think of
the qwerks involved in testing untested software. So they quickly give up
and avoid beta testing like the plague. Beta testing requires a person to
do nearly as much work (if not actually more) as the programmer themself.
Programs can't evolve without testers actually running the program and at
least trying to make it work even with the bugs in it. True beta testers
don't seem to know the meaning of the phrase "I give up", and that's what
makes being a program author worth while. I couldn't give a damn if I get
one more program registration in my life, so long as there are dedicated
common sense thinking people like this standing by you, it's worth while!
Let's here it for the people that refused to say "I give up"!
Name: BBS: Phone:
───────────────────────────────────────────────────────────────────────────
Brad Larned (1:205/400) The Fresno Online BBS 209-276-3657
Sean Price (1:205/46) Sanctuary From The Law BBS 619-377-3611
Chris Martin (1:219/308) The Mars Station BBS 760-254-3012
Bob Wingender (1:284/11) The Oak Tree BBS 417-581-0868
Chet Rhodes (1:151/124) Hawkmoon's Realm 919-556-8363
Larry Thrasher (1:3612/650) The Night Thrasher BBS 904-937-9144
Thomas Wells (1:3621/1) Renegade's Hideout 615-326-5597
Timothy Barney (1:2622/3) The Gravel Pit 814-942-1552
Cliff Williams (1:112/124) The City Of Thought 904-645-8850
Jon Parise (1:2606/421) Infinite Twilight 908-637-8243
Arthur Stark (1:395/670) Top's Diamond Mine 254-542-8783
Ronald Schlegel (1:110/1065) Dynasty BBS 937-258-1030
David Raasch (1:280/285) Let It Shine Online! 816-461-2290
───────────────────────────────────────────────────────────────────────────
NOTE: These names appear in no particular order, they are only listed here
as the names appear in my MAX Graphics area message base...
───────────────────────────────────────────────────────────────────────────────
The Golden Rule Of Writing TDK MAX Doors:
─────────────────────────────────────────
First of all, before you even attempt to write a TDK MAX door, or a MAX door
with any other door development kit, read MAXINFO.DOC in its entirety so you
understand exactly how MAX Graphics works. Don't be scared of this rule, you
will see that using the MAX language is almost identical to using Pascal, so
you will definitely be able to grasp this concept with no problems at all...
It is imperative that you fully understand how MAX Graphics and MAXterm work
with each other before you attempt to write a MAX door...If you just jump in
to this thing head first without looking ahead of time, chances are that you
will end up injuring your head. Most likely from banging your head against a
wall trying to figure out why something isn't working like you want it to...
MAX Graphics is totally unlike RIP...You can actually learn MAX and memorize
it just like a programming language...The most important thing about writing
a MAX door is to not allow yourself to be initimidated, you are only writing
a program to send text to the remote. All of the low level stuff is actually
handled by MAXterm...So don't be scared, and don't make things hard, because
you now have a way of making SVGA doors just as simple as if you were making
a plain old ANSI/ASCII door...
───────────────────────────────────────────────────────────────────────────────
About The MAXDOOR Archive:
──────────────────────────
This archive contains sample source code to show the principals of writing
MAX compatible doors. This document is not a replacement for MAXINFO.DOC,
so be sure you read that sucker over and over until you have bad dreams of
little MAX commands attacking you in your sleep... :) What follows here
are special considerations to keep in mind about the concepts used in the
MAXDOOR.PAS sample program, in the order they appear in that program...
───────────────────────────────────────────────────────────────────────────────
Displaying MAX Screen Files With TDK:
─────────────────────────────────────
Regarding DOORKIT3.PAS / PROCEDURE ShowScreen(Scr : STRING);
You don't have to do anything special in your doors to display screen files
with TDK. MAX screen files don't even need to have the ASCII #12 in them to
clear the remote screen because TDK automatically sends it if it detects a
user is running MAXterm. If TDK detects MAXterm, all MAX screen commands are
sent directly to the comport rather than being scrolled up the screen. When
MAXterm is detected, a simple banner is printed at the bottom of the screen
telling you that it is displaying the screen file to the remote. This looks
better than having a bunch of garbage commands rolling about the screen. TDK
also does the same thing in the event of RIP and AVATAR callers as well...
If you want to have more than one MAX window on the screen at once, you can
tell TDK not to send the ASCII #12 to kill the screen. There is a variable
in TDK called "NoKill". If you make a call to "NoKill := TRUE;" before you
display a MAX screen file, and so long as your screen file itself does not
contain an ASCII #12 or Start_Screen() command at the beginning, the screen
file contents will overlap the previous screen. In this case, you will want
to make sure that your screen starts with a Hide_Mouse() command, and that
you insert a Show_Mouse() command before the End_Screen() command...
───────────────────────────────────────────────────────────────────────────────
Displaying Text Files With TDK:
───────────────────────────────
Regarding DOORKIT3.PAS / PROCEDURE ShowTextFile(TextFile : STRING);
Displaying a text file to a MAXterm user can be done in two ways, you can
either use the built in text file reader in MAXterm, so long as your text
file contains no more than 800 lines. Or, you can use the procedure in TDK
to display a text file of unlimited size. The main advantage to using the
text file displaying procedure in TDK is that unlike the text file viewer
in MAXterm, the text file doesn't need to first exist on the user's system
in the ?:\MAXTERM\SESSION\ subdirectory...
The ShowTextFile procedure in DOORKIT3.PAS simplifies displaying text files
to the remote caller no matter what terminal emulation they support. In MAX
Graphics mode, this procedure sends a list of commands to draw a text file
reader on the screen with buttons at the bottom for scrolling through the
file. All Hide_Mouse() and Show_Mouse() procedures are handled automatically
All you do is tell the procedure the path and file name of the text file and
that's it.
You may still use MAXterm's internal text file viewer with a TDK MAX door if
you wish. However, you will have to write the commands into your program to
read the text file and send it using the Start_Text_File, Put_Text_File, and
End_Text_File MAX commands. It's up to you how you want to do things, I just
added the ShowTextFile procedure in TDK to simplify things for you...
───────────────────────────────────────────────────────────────────────────────
Sending Actual MAX Commands To The Caller:
──────────────────────────────────────────
Regarding MAX_UNIT.PAS / PROCEDURE MaxCommand(S : STRING);
This procedure is included in TDK to help automate and simplify the sending
of MAX commands, and handle any return data that certain MAX commands make
MAXterm return to your program. As you know from reading MAXINFO.DOC, there
are some MAX commands that make MAXterm kick back data to your program, so
you need a way of handling this data. What would be great is if there was a
way to handle this data in a simple kindergarten level manner. Well, that's
what this procedure does. Any time MAXterm kicks back any data like that,
the MaxCommand procedure will write this data to text files in the current
program directory. All text files use file names that are node specific so
as to prevent interference with the same program running on other nodes...
You may send MAXscript, MAXcontrol, and MAXcolor commands with MaxCommand,
all commands are sent with a carriage return & line feed combination at the
and, so you don't have to worry about adding a #13#10 at the end of them...
What follows below are various examples of how the MaxCommand procedure is
used in a TDK MAX door, and how any return data is handled and stored...
───────────────────────────────────────────────────────────────────────────────
Special Considerations Regarding MAX Entry Fields:
──────────────────────────────────────────────────
When writing MAX doors, there are some things you need to keep in mind about
the way MAXterm works. One thing you will probably think is ass backwards is
that ALT keypresses in MAXterm actually work over the modem. Well, I should
say that they "Partially" work, MAXterm doesn't send the initial ASCII #0 or
NUL character, it only sends the secondary extended scan code. This is done
this way because there are certain internal features in MAXterm that use ALT
keypresses and normal keypresses at the same time...
Take the entry fields for example. Users type things as normal in an entry
field, and if there are more than one entry field on the screen, the <TAB>,
<ENTER> and arrow keys scroll through the fields. Well, you need a way to
get out of the entry fields and tell the door that you are out of them...So,
this is why the ALT keypresses actually work over the modem. Unlike straight
ANSI/ASCII doors written with TDK, when you use entry fields with MAXterm,
all the work is actually done within MAXterm itself. Things are done in this
way because it eliminates the need to keep a constant flow of ANSI escape
sequences running back and forth, thus resulting in a faster and smoother
operation for both programs at the same time...
In the example MAXDOOR.PAS program, you will see that the entry field demo
looks for an ASCII #24 to tell the door to query MAXterm for the text that
the user typed in the entry fields. The FDEMO.MAX screen has two buttons in
it, one assigned to an ALT-O (ASCII #24) for "Okay", and the other assigned
to ALT-Q (ASCII #16) for "Quit"...Both buttons are assigned to and ALT key
so the user can escape the loop in MAXterm that runs the entry fields, and
the ordinal value assigned to each button is sent back to your door so you
can trap it in the program and handle the required procedures...
Querying MAXterm For Entry Field Data:
──────────────────────────────────────
In the example MAXDOOR.PAS program, you will see that the entry field demo
uses the MaxCommand procedure to force MAXterm to kick back the contents of
all the entry fields in the current window. As you know by reading the file
MAXINFO.DOC, every MAX command has two versions. One MAXscript command that
is humanly readable, and the MAXcontrol counterpart that really isn't that
readable. I prefer to use MAXcontrol for everything because it's faster and
I seldomly ever have to read through my screen files. If I do, then I just
load up the screen in MAXpaint and read it that way...
In the example program I use the Get_Field_Data command to tell MAXterm that
I need the text from all of the current entry fields to be sent back to me.
When you make a call to the procedure MaxCommand('Get_Field_Data()'); or
MaxCommand(#255#126#250#255); special procedures are automatically taken care
of for you by the MAX_UNIT.PAS unit to obtain the entry field text...
The text from each entry field in MAXterm will be written to a file on your
hard drive. The file name is FIELDS.### where the ### represents the current
node number (ie: FIELDS.1 through FIELDS.255). The text is written to this
file in the same order that the entry fields are plotted on the screen in
MAXterm. After you send the Get_Field_Data command, simply look for the text
file on the hard drive in the current directory. If the file exists, then
the transfer of field data was successful, and you can now read the data out
of the text file, then apply it to your door as needed...
───────────────────────────────────────────────────────────────────────────────
Special Considerations Regarding MAX PickLists:
───────────────────────────────────────────────
As you probably know, the little "ANSI LightBar Menu" feature in some BBSes
is just the coolest thing in the world to some sysops. I find it boring and
a waste of time because a single keypress accesses a menu function faster..
But, for those people that like the LightBar effect, there is a feature in
MAX Graphics to allow something similar. This is called a "PickList" in MAX
Graphics and they work similar to the scrolling selection menus in Windows
or OS/2. You can have a little box on the screen that only shows ten items
in it at once, but it can actually have up to 800 items to choose from. The
items scroll through the little box with a highlight bar which is used for
selecting an item in the picklist. You can use your mouse to select/scroll
the items, your arrow keys, your Page-Up/Page-Down keys, or a combination
of CTRL-Page-Up/CTRL-Page-Down to jump to the top or bottom of the picklist.
PickLists must be initialized, stuffed, and activated in exactly that order.
An example of this would be:
New_PickList(100,100,3,30) {PickList Initialization}
AddTo_PickList('Item #1') {PickList Stuffing}
AddTo_PickList('Item #2') {" "}
AddTo_PickList('Item #3') {" "}
AddTo_PickList('Item #4') {" "}
AddTo_PickList('Item #5') {" "}
SetUp_PickList() {PickList Activation}
This sequence of MAX commands (excluding the {Comments}) initializes a new
picklist on the screen at the coordinates 100/100. The picklist only allows
3 items to to appear on the screen at any one time, and the picklist allows
up to 30 characters of each item to display on the screen. Now, even though
only 3 items are displayed at any one time, the picklist actually contains
5 items that will scroll through the picklist field on the screen...
It is critical that you execute these commands in the order that they appear
in the above example, the reason for this is fully detailed in MAXINFO.DOC..
You may have up to 800 AddTo_PickList(' ') commands in the screen file, so a
picklist can really be HUGE, but only have a small fraction of items on the
screen...
The SetUp_PickList() command is what actually draws out the picklist items
on the screen. Let's say that you wanted the picklist to default to another
item besides number 1 when it is activated. You can do this by a call to the
Reset_PickList() command before the SetUp_PickList() command. Say that your
picklist has 500 items in it, and you want it to always default to item 250
when it draws. Simply insert a Reset_PickList(250) before SetUp_PickList...
The most important thing to keep in mind about picklists is that they MUST
appear in the screen before any other buttons. This is because the buttons
in the picklist are automatically assigned to buttons number 1 and 2. This
is something you will never have to worry about if you make your screens in
MAXpaint, because it has built in intelligent MAX syntax checking. However,
if you are manually writing your screens just as if you were using graphics
commands in a programming language, you have to make sure that you get the
commands in the screen in the correct place, and in the correct order...
Detecting The Selected PickList Item:
─────────────────────────────────────
Now that you know how to properly place a picklist on the screen, how does a
person tell when the user selects an item, and which item is selected? This
is just as simple as obtaining the field data mentioned in the above. If you
look at the picklist example code in MAXDOOR.PAS, you'll see that things are
done the same way. Meaning, you check for ALT keypresses and tell MAXterm to
send data back that is written to a text file on your hard drive...
In the example code, the screen file containing the picklist uses an ALT-S
keypress assigned to a button labeled "Select" in the screen file. When the
button is clicked, or when the user presses ALT-S, MAXterm will return an
ASCII #31 to your door. If you receive an ASCII #31, then you know that you
need to use the MaxCommand procedure to tell MAXterm to report which item
in the picklist has the highlight bar on it. Again, there are two different
commands that will tell MAXterm to send back this information:
MaxCommand('Get_Pick_Info()'); { MAXscript Get_Pick_Info }
MaxCommand(#255#126#247#255); { MAXcontrol Get_Pick_Info }
When MAXterm sends the information back, you will end up with a file on the
hard drive in the current directory. The file name is PICKINFO.### where the
### represents the current node number (ie: PICKINFO.1 thru PICKINFO.255)...
In this text file, there will be two lines of text. The first line will show
the actual number of the selected picklist item, and the second line will be
the actual text string of the selected picklist item. Once you have the file
on your hard drive, you just read the file and apply the data to your door
as needed...
───────────────────────────────────────────────────────────────────────────────
Using MAXterm Text View Ports:
──────────────────────────────
The use of Text View Ports in your doors can help you cut down your program
overhead in a major way because it allows you to share the same text output
routines that your door's ANSI side uses in the door's MAX side as well...
If you look at the Text View Port Example in MAXDOOR.PAS, you will see that
it uses the OutTxt procedure to print the text just like you would use in an
ANSI/ASCII door. Another thing is that even though there is active graphics
on the screen (meaning anything changing after the window is drawn) text in
the port will not cause "Mouse Warts" on the screen if the mouse happens to
be within the port while the text is drawing. This is all handled within the
terminal program, so there is no need to send a bunch of mouse hide and show
commands to the remote...
Also, as a review note...Text View Ports can be up to 79 columns wide, and
up to 25 rows high. You can essentially draw a full size ANSI screen within
a Text View Port if you wish to...
───────────────────────────────────────────────────────────────────────────────
Internal Screen Files:
──────────────────────
If you don't want to have a bunch of separate screen files lying around the
hard drive, you can easily put your screen files right into your program...
The MAXTOPAS.EXE utility will read a MAX screen file and create an include
file that you can link into your program. The screen file will be converted
to an individual procedure. If your screen file is MAINMENU.MAX, the utility
will read the file and create a procedure called Mainmenu_Max in a separate
include file (MAXTOPAS.INC)...Simply add a {$I MAXTOPAS.INC} in your program
and call the procedures as needed. Every time you run MAXTOPAS.EXE, it will
look for the MAXTOPAS.INC file. If it doesn't exist, it will be created, if
it does exist, all screens will be appended to the end of the file...
You will most likely want to overlay the unit that calls these procedures
because it will end up taking a big hunk out of the conventional memory if
you have a lot of internal screen files. If you overlay them, then they will
be held in XMS, EMS, or in the overlay on the disk. All of this is handled
automatically by the OVERXMS.PAS unit. Be sure to keep backup copies of your
screen files in the event you want to change them in the future. Also, you
will have to save your screen files with the ASCII #12 in them before they
are converted if you don't want screens to constantly overlap each other...
See the file MAXDOOR.INC and how the file is linked into MAXDOOR.PAS for a
clearer idea of how all of this works...
HEY - THIS IS IMPORTANT!
────────────────────────
You don't have to include full icon libraries with your doors. If your door
only uses two or three icons, you can chop the library down so there are
only the required icons for your door included in the library. Doing this
also protects your icons from being modified because neither MAXpaint, or
the icon editor in the MAXterm Plug-Ins will load an icon library unless it
has 100 icon records in it...
Below is a basic example of how you can chop any icon library down to size
for use with your door. When a door displays an icon, all you do is seek to
a specific record location, so just put all of your icons at the beginning
of the icon library and never try to seek past the highest record number.
It also makes for a much faster transfer of your icons in resource updates.
{$A+,B-,D+,E+,F+,G+,I-,L+,N-,O+,P-,Q-,R-,S-,T-,V+,X+}
PROGRAM ICONCHOP; {This code is courtesy of Brad Larned / FzSoft}
USES CRT,DOS;
TYPE Icon16x16 = RECORD
Matrix : ARRAY[1..16,1..16] OF BYTE;
END;
TYPE Icon30x30 = RECORD
Matrix : ARRAY[1..30,1..30] OF BYTE;
END;
TYPE Icon60x60 = RECORD
Matrix : ARRAY[1..60,1..60] OF BYTE;
END;
VAR
I16 : Icon16x16;
Dat16 : FILE OF Icon16x16;
D16 : FILE OF Icon16x16;
I30 : Icon30x30;
D30 : FILE OF Icon30x30;
Dat30 : FILE OF Icon30x30;
I60 : Icon60x60;
D60 : FILE OF Icon60x60;
Dat60 : FILE OF Icon60x60;
FName1 : STRING;
FName2 : STRING;
Stop : BYTE;
Count : BYTE;
{───────────────────────────────────────────────────────────────────────────}
FUNCTION StrToInt(S : STRING) : LONGINT;
VAR
L : LONGINT;
U : INTEGER;
BEGIN
VAL(S,L,U);
StrToInt := L;
END;
{───────────────────────────────────────────────────────────────────────────}
FUNCTION Exist(Filename : STRING) : BOOLEAN;
VAR
Inf : SEARCHREC;
BEGIN
FINDFIRST(Filename,AnyFile,Inf);
Exist := (DOSERROR = 0);
END;
{───────────────────────────────────────────────────────────────────────────}
{ ICONCHOP.EXE OldFile Newfile Count }
{ Paramstr(1) = Current Icon Library Name }
{ Paramstr(2) = New Icon Library Name }
{ Paramstr(3) = New Icon Count - Cut here }
BEGIN
IF PARAMCOUNT = 3 THEN BEGIN
FName1 := PARAMSTR(1);
FName2 := PARAMSTR(2);
Stop := StrToInt(PARAMSTR(3));
IF (Stop = 0) OR (Stop > 100) OR (NOT Exist(FName1)) OR (FName1 = FName2) THEN HALT;
Count := 1;
IF POS('.001',FName1) > 0 THEN BEGIN { 16 x 16 Icon Sets }
WRITELN('16 x 16 Icon Library Detected...');
ASSIGN(Dat16,FName1);
ASSIGN(D16,FName2);
RESET(Dat16);
REWRITE(D16);
WHILE (NOT EOF(Dat16)) AND (Count <= Stop) DO BEGIN
INC(Count);
READ(Dat16,I16);
WRITE(D16,I16);
END;
CLOSE(D16);
CLOSE(Dat16);
END ELSE IF POS('.002',FName1) > 0 THEN BEGIN { 30 x 30 Icon Sets }
WRITELN('30 x 30 Icon Library Detected...');
ASSIGN(Dat30,FName1);
ASSIGN(D30,FName2);
RESET(Dat30);
REWRITE(D30);
WHILE (NOT EOF(Dat30)) AND (Count <= Stop) DO BEGIN
INC(Count);
READ(Dat30,I30);
WRITE(D30,I30);
END;
CLOSE(D30);
CLOSE(Dat30);
END ELSE IF POS('.003',FName1) > 0 THEN BEGIN { 60 x 60 Icon Sets }
WRITELN('60 x 60 Icon Library Detected...');
ASSIGN(Dat60,FName1);
ASSIGN(D60,FName2);
RESET(Dat60);
REWRITE(D60);
WHILE (NOT EOF(Dat60)) AND (Count <= Stop) DO BEGIN
INC(Count);
READ(Dat60,I60);
WRITE(D60,I60);
END;
CLOSE(D60);
CLOSE(Dat60);
END;
WRITELN;
WRITELN('All Done, New Icon Library ',FName2,' length set at (',Stop,') Icons ..');
WRITELN;
END ELSE WRITELN('ICONCHOP.EXE OldFile Newfile Count');
END.
───────────────────────────────────────────────────────────────────────────────
Implementing MAXecutables:
──────────────────────────
MAXterm is also capable of a very special feature which allows you to write
doors that also run on the user's system. These are referred to as (what I
call) a MAXecutable file. These are special executables that run in MAXterm's
\SESSION\ subdirectory. These executables are called with MAXterm's program
home directory as the only command line parameter. MAXecutables must also
read the \MAXTERM\SESSION\MAXINFO.DEF drop file, this is a custom drop file
that is created every time MAXterm receives the MAXecute() script command.
Here is how MAXecutables work with MAXterm:
1. A MAXecutable is a standard executable file with the exception that it has
to be run in the \SESSION\ subdirectory of MAXterm. You can still run them
locally by feeding them false information in their start up files, this is
needed for development. A MAXecutable is designed to read a MAXINFO.DEF
drop file to get all of the required communications parameters, user name,
etc.
2. When you send the MAXecute('FILENAME.EXE') command, MAXterm will do this:
(a) Write a MAXINFO.DEF drop file in the \SESSION\ subdirectory.
(b) Close the comport while leaving the DTR hot.
(c) Shut down the graphics mode (ie: RestoreCrtMode;).
(d) Change to MAXterm's \SESSION\ subdirectory.
(e) Execute FILENAME.EXE with MAXterm's home directory as ParamStr(1).
(f) Change back to the MAXterm home directory.
(g) Restart the graphics mode (ie: SetGraphMode(GetGraphMode);).
(h) Restore the previous SVGA screen.
(i) Re-open the comport.
(j) Send an ASCII #13 to the comport indicating a successful return.
3. While the MAXecutable is running, you have 100% control over everything,
MAXterm is no longer active in any way whatsoever. So it is completely up
to you to monitor for carrier, inactivity timeouts, etc. This also means
that you can now do things that are impossible within the constraints of
the MAXscript/MAXcontrol/MAXcolor language. You could theoretically run a
program of any other graphics resolution, the TDK and UltraBGI kits are
by no means required for MAXecutables.
Technically, a MAXecutable is simply a remote operated door. It's not rocket
science, it's simply a way of giving door programmers unlimited possibilities
and total freedom of program design. When writing MAXecutable programs, you
need to look at things kind of backwards. The remote system actually becomes
the host in a sense. Just like any standard ANSI terminal, MAXterm doesn't
know anything about how much time a use has left. So you will need to make
some type of a "Server" program that runs as a door off of the BBS. This may
be needed to transfer the actual MAXecutable from the BBS to the remote, and
absolutely will be required to get any information about the user from the
BBS to the remote. There are no standardized commands or methods to do this,
so the server is an absolute must. The server may also be needed to send and
receive score data files or other critical system related files.
The MAXINFO.DEF Drop File:
──────────────────────────
When a BBS or a door send the MAXecute command to your terminal program, it
will create a special drop file for the MAXecutable program to read...Below
is a line by line definition of the MAXINFO.DEF system drop file:
1. The user's name stored in the current dialing directory entry.
2. The user's password stored in the current dialing directory entry.
3. Use SoundBlaster: "TRUE" or "FALSE" (without quotes).
4. Current .PKG file name in use with no .PKG extension.
5. Program upload path.
6. Program download path.
7. System archiver path.
8. System default archiver (1=ZIP, 2=LHA, 3=ARJ, 4=RAR, 5=Custom).
9. Custom archiver batch file name.
10. Custom unarchiver batch file name.
11. Custom external protocol upload batch file name.
12. Custom external protocol download batch file name.
13. Current comport in use (1 to 8).
14. Current comport hex address (0 for standard address).
15. Current comport IRQ (0 for standard IRQ).
16. Current comm device (1=UART, 2=Fossil, 3=DigiBoard).
17. Current comport port speed (ie: locked port rate).
18. Current connection speed (ie: caller's actual baud rate).
19. Current comport input buffer size in bytes.
20. Current comport output buffer size in bytes.
21. Using hardware flow control: "TRUE" or "FALSE" (without quotes).
22. Modem initialization string #1.
22. Modem initialization string #2.
22. Modem initialization string #3.
23. Modem answer string.
24. Modem on hook string.
25. Modem off hook string.
26. Modem dialing string.
NOTE: MAXterm only uses 8-N-1 communications....If I was interested in any
kind of 7 bit communications stuff or any internet programming, this
archive would say that is was from "Internet Utiliteez Software"....
───────────────────────────────────────────────────────────────────────────────
┌───────────────────────────────────────────────────────────────────┐
│ │
│ ┌── ┌────── ┌────── ┌────── ┌────── ┌──────── │
│ ┌── ┌── ┌── ┌── ┌── ┌── ┌── ┌── │
│ ┌── ┌──────── ┌──── ┌────── ┌── ┌── ┌──── ┌── │
│ ┌── ┌── ┌── ┌── ┌── ┌── ┌── ┌── │
│ ┌────── ┌── ┌── ┌────── ┌────── ┌── ┌── │
│ │
└───────────────────────────────────────────────────────────────────┘
Not just software....It's a computer enhancement!
┌───────────────────────────────────────────────────────────────────┐
│ Contact: 1:14/703@FidoNet Or: USA MAX Graphics HQ-BBS │
│ 411:1500/0@ivNET (308)762-2239 │
│ 121:101/2@AllianceNet FAX or Data Calls │
│ maxgfx@juno.com ANSI/ASCII/MAX (No RIP) │
└───────────────────────────────────────────────────────────────────┘
───────────────────────────────────────────────────────────────────────────────